The bitcoin system was developed to allow electronic cash to be transferred directly from one party to another without going through a financial institution, as described in the white paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto. A bitcoin (e.g., an electronic coin) is represented by a chain of transactions that transfers ownership from one party to another party. To transfer ownership of a bitcoin, a new transaction is generated and added to a stack of transactions in a block. The new transaction, which includes the public key of the new owner, is digitally signed by the owner with the owner's private key to transfer ownership to the new owner as represented by the new owner public key. Once the block is full, the block is “capped” with a block header that is a hash digest of all the transaction identifiers within the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called a “blockchain.” To verify the current owner, the blockchain of transactions can be followed to verify each transaction from the first transaction to the last transaction. The new owner need only have the private key that matches the public key of the transaction that transferred the bitcoin. The blockchain creates a mathematical proof of ownership in an entity represented by a security identity (e.g., a public key), which in the case of the bitcoin system is pseudo-anonymous.
To ensure that a previous owner of a bitcoin did not double-spend the bitcoin (i.e., transfer ownership of the same bitcoin to two parties), the bitcoin system maintains a distributed ledger of transactions. With the distributed ledger, a ledger of all the transactions for a bitcoin is stored redundantly at multiple nodes (i.e., computers) of a blockchain network. The ledger at each node is stored as a blockchain. In a blockchain, the transactions are stored in the order that the transactions are received by the nodes. Each node in the blockchain network has a complete replica of the entire blockchain. The bitcoin system also implements techniques to ensure that each node will store the identical blockchain, even though nodes may receive transactions in different orderings. To verify that the transactions in a ledger stored at a node are correct, the blocks in the blockchain can be accessed from oldest to newest, generating a new hash of the block and comparing the new hash to the hash generated when the block was created. If the hashes are the same, then the transactions in the block are verified. The bitcoin system also implements techniques to ensure that it would be infeasible to change a transaction and regenerate the blockchain by employing a computationally expensive technique to generate a nonce that is added to the block when it is created. A bitcoin ledger is sometimes referred to as an Unspent Transaction Output (“UTXO”) set because it tracks the output of all transactions that have not yet been spent.
To enable more complex transactions than bitcoin can support, some systems use “smart contracts.” A smart contract is computer code that implements transactions of a contract. The computer code may be executed in a secure platform (e.g., an Ethereum platform, which provides a virtual machine) that supports recording transactions in blockchains. In addition, the smart contract itself is recorded as a transaction in the blockchain using an identity token that is a hash (i.e., identity token) of the computer code so that the computer code that is executed can be authenticated. When deployed, a constructor of the smart contract executes, initializing the smart contract and its state. The state of a smart contract is stored persistently in the blockchain. When a transaction is recorded against a smart contract, a message is sent to the smart contract, and the computer code of the smart contract executes to implement the transaction (e.g., debit a certain amount from the balance of an account). The computer code ensures that all the terms of the contract are complied with before the transaction is recorded in the blockchain. For example, a smart contract may support the sale of an asset. The inputs to a smart contract to sell a car may be the identity tokens of the seller, the buyer, and the car and the sale price in U.S. dollars. The computer code ensures that the seller is the current owner of the car and that the buyer has sufficient funds in their account. The computer code then records a transaction that transfers the ownership of the car to the buyer and a transaction that transfers the sale price from the buyer's account to the seller's account. If the seller's account is in U.S. dollars and the buyer's account is in Canadian dollars, the computer code may retrieve a currency exchange rate, determine how many Canadian dollars the seller's account should be debited, and record the exchange rate. If either transaction is not successful, neither transaction is recorded.
When a message is sent to a smart contract to record a transaction, the message is sent to each node that maintains a replica of the blockchain. Each node executes the computer code of the smart contract to implement the transaction. For example, if 100 nodes each maintain a replica of a blockchain, then the computer code executes at each of the 100 nodes. When a node completes execution of the computer code, the result of the transaction is recorded in the blockchain. The nodes employ a consensus algorithm to decide on which transactions to keep and which transactions to discard. Although the execution of the computer code at each node helps ensure the authenticity of the blockchain, it requires large amounts of computer resources to support such redundant execution of computer code.
Although blockchains can effectively store transactions, the large amount of computer resources, such as storage and computational power, needed to maintain all the replicas of the blockchain can be problematic. To overcome this problem, some systems for storing transactions do not use blockchains, but rather have each party to a transaction maintain its own copy of the transaction. One such system is the Corda system developed by R3, Ltd., which provides a decentralized distributed ledger platform in which each participant in the platform has a node (e.g., computer system) that maintains its portion of the distributed ledger. When parties agree on the terms of a transaction, a party submits the transaction to a notary, which is a trusted node or cluster of nodes, for notarization. The notary maintains an UTXO database of unspent transaction outputs or alternatively spent transaction outputs. When a transaction is received, the notary checks the inputs to the transaction against the UTXO database to ensure that the outputs referenced by the inputs have not been spent. If the inputs have not been spent, the notary updates the UTXO database to indicate that the referenced outputs have been spent, notarizes the transaction (e.g., by signing the transaction or a transaction identifier with a public key of the notary), and sends the notarization to the party that submitted the transaction for notarization. When the party receives the notarization, the party stores the notarization and provides the notarization to the counterparties.
Transactions between parties in a distributed ledger system can involve complex interactions between the nodes of the parties. To help support such transactions, a protocol framework that supports the development of protocol flows may be employed. A protocol flow (or simply “flow”) is computer code that controls the performance of a transaction by the party or parties to the transaction. Protocol flows can be developed for different types of transactions, such as a transaction to sell an asset from a selling party to a buying party, a transaction to support an interest rate swap, a transaction involving more than two parties, and so on. An example will help illustrate a protocol flow. In this example, a “transfer” transaction specifies to transfer a certain amount of money from an “originator” party to a “responder” party. To support such a transfer transaction, a transfer protocol flow may be developed that includes computer code for the party in the role of the originator (“originator code”) and computer code for the party in the role of responder (“responder code”). When the two parties agree to consummate the transaction, they agree on the particulars of the transaction, such as the amount of money to transfer, the notary who is responsible for notarizing the transaction, and the use of the transfer protocol flow.
Continuing with the example of the transfer transaction, to record the transfer transaction, the originator party starts execution of the originator code of the transfer protocol flow, and the responder party starts execution of the responder code of the transfer protocol flow. The originator party provides the particulars of the transaction to the originator code. The originator code then sends to the responder party its public key and the particulars of the transaction. Upon receiving the public key and the particulars of the transaction, the responder code verifies the particulars of the transaction (e.g., prompting a user to confirm the price), generates a proposed transaction that outlines the particulars of the transaction, signs the proposed transaction with the signature of the responder party (e.g., using a private key of the responder party), and sends the proposed transaction to the originator code. The proposed transaction specifies the input state and the output state and identifies a notary. The input state may specify the funds used to buy the asset, and the output state may specify that ownership of the asset has been transferred. The input state and the output state include contract code that is used to verify whether the transaction is valid. Upon receiving the proposed transaction, the originator code verifies the proposed transaction by verifying that the proposed transaction was signed by the responder party (e.g., using the public key of the responder party), verifying that the particulars of the proposed transaction match those sent to the responder party, and executing the contract code of the input state and output state of the proposed transaction to determine whether the proposed transaction is valid according to the contract code. When the proposed transaction is valid, the originator code accepts the proposed transaction by signing the proposed transaction with the signature of the originator party to generate an accepted transaction. The originator code then sends the accepted transaction to notary code of the notary specified in the proposed transaction. The notary code may be considered computer code of the transfer protocol code for the role of notary. Execution of the notary code may have started when the parties decided to consummate the transaction. Execution of the code of the transfer protocol flows continues by the parties as described in U.S. Patent Application Publication Number US2017/0352012A1, entitled “Secure Processing of Electronic Transactions by a Decentralized, Distributed Ledger System,” with the applicant of R3 Ltd., and published on Dec. 7, 2017, which is hereby incorporated by reference. This patent publication provides an example of a protocol framework.
Cyberattacks cost companies and individuals billions of dollars. A report in 2015 estimated that cyberattacks cost companies over $400 billion annually. In addition to the financial costs, cyberattacks may result in other damages such as the destruction of valuable information, the release of sensitive information, and so on. The costs and damages will surely increase over time without effective defenses. Cyberattacks often rely on malicious software, referred to as “malware,” which is installed and executed by a computer that is the target of the attack. The executing malware orchestrates the attack. For example, a ransomware attack may encrypt all the data on a computer, including the only copies of financial documents, family photographs, electronic mail messages, and so on. If the ransom is not paid, then the data may remain encrypted forever. Even if the ransom is paid, the attacker might not provide the key to decrypt the data. As another example, if an organization's node of a distributed ledger system is the subject of a successful cyberattack, the attacker may be able to create transactions and record the transactions in a way that steals assets (e.g., account information, trade secrets, customer lists, private keys, and other business data) from the organization, enter into contracts with other organizations, and so on. Because of the high costs of cyberattacks, companies and individuals expend considerable resources in developing and purchasing security systems as defenses to cyberattacks.